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PREFACE 


PrograTnming  languages  and  compilers  like  ALG0L  and  the  ALC^^R- 
ILLIN0IS-7O9O  ALG0L-6O  Translator  are  designed  to  make  programining  as 
convenient  and  as  machine  independent  as  possible.   The  purpose  of  an  Algol 
program  is  simply  to  define  an  algorithm.   From  this  point  of  view^  it  is 
completely  uninteresting  whether  this  algorithm  is  executed  by  a  human  or  an 
electronic  computer^  how  the  representation  of  the  algorithm  in  the  internal 
language  of  a  machine  looks,  or  how  the  operating  system  of  a  specific  computer 
is  designed  and  organized. 

It  is  desirable  to  apply  this  philosophy  not  only  to  programming,  but 
to  the  debugging  of  programs  as  well  since  the  conventional  dumps  of  machine 
conditions,  storage  areas  and  the  object  code  are  either  entirely  useless  or 
provide  mainly  superfluous  and  irrelevant  information  which  makes  debugging  a 
tedious  task. 

A  post  mortem  dump  of  an  Algol  program  should  only  give  information 
relevant  to  the  determination  of  the  cause  of  the  breakdown.   Reference  should 
be  made  to  the  source  program  rather  than  to  the  object  code  whenever  possible. 
Furthermore  this  information  should  be  communicated  in  a  language  that  can  be 
understood  by  humans  directly  without  applying  a  cascade  of  decodings  first. 

The  ALC0R -ILLINOIS -7090  P0ST  M^^fRTEM  DUMP  was  designed  with  these 
objectives  in  mind.   It  is  the  hope  of  the  designers,  that  at  least  some 
approximation  of  the  objectives  has  been  achieved. 


Urbana 


Munich 


January  1966 


The  designers:  Rudolf  Bayer 
Jerome  Cohen 
David  Gries 
Dr.  M.  Paul 
Robert  Penka 
Dr.  R.  Wiehle 
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ORGANIZATION  AND  IMBEDDING  INFORMATION 


I.   Introduction 


The  Post  Mortem  Dump  (PM)UMP)  for  the  ALCSZ5R-ILLIN0IS-7O9O  ALG0L-6O 
Translator  is  designed  to  give  a  structural  analysis  of  an  Algol  program  at  the 
time  of  a  hangup  or  breakdown  and  to  print  out  the  names  of  all  living  variables 
(i.e.^  variables  which  are  defined  at  the  hangup  point  in  the  program)  together 
with  their  actual  values. 

PMDUMP  can  be  implemented  as  an  integral  part  of  an  operating  system 
as  a  system  routine  which  is  called  into  core  by  the  connecting  execution  time 
subroutine  )PREPM  in  casu  mortis  or  it  can  be  used  as  a  separate  core  load 
which  is  called  by  )PREPM. 

In  the  analysis  made  by  PMDUMP  references  to  object  code^  machine 
language  and  octal  core  dumps  are  avoided  almost  entirely  (for  an  option  see 
the  parameter  ESCAPE).   To  achieve  this  goal  it  is  necessary  to  generate  at 
compilation  time  some  information  about  the  generated  object  code  in  order 
to  make  a  later  analysis  feasible. 

This  dump  information  is  saved  on  logical  tape  UTAPl  (see  PMDUMP 
parameters  and  section  IV) . 
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II.   General  Organization  of  PMDW4P 


If  a  Post  Mortem  Dump  is  requested  for  an  Algol  program  (see 
compiler  parameters  PMDMPL;  PMDMPB)  then  Pass  3  of  the  compiler  generates 
the  necessary  dump  information_,  writes  it  on  UTAPl  and  generates  a  call  of 
)PREPM  at  the  very  beginning  of  the  object  program.   )PREPM  is  an  execution 
time  subroutine  which  sets  proper  error  returns  for  the  system^  initializes 
time  traps  to  allow  sufficient  time  to  give  a  dump^  stores  a  special  core 
constant^  etc,  (for  details  see  separate  description  of  )PREPM). 

In  casu  mortis  control  is  returned  to  )PREPM  which  now  saves 
machine  conditions  as  far  as  necesssary  or  possible^  determines  the  cause  of 
the  breakdown  and  compiles  this  necessary  information  to  pass  it  on  to  PMBUMP, 
Also  )PREPM  saves  the  object  code  area  and  the  working  storage  area  of  the 
dead  core  memory  on  UTAPM2  and  UTAPM3  respectively  and  finally  calls  the 
routine  PMDUMP  as  a  new  core  load  or  as  a  system  routine. 

The  main  task  of  )PREPM  is  to  connect  PMDUMP  to  a  special  operating 
system.   Therefore  )PREPM  is  highly  system  dependent  and  must  be  written  at 
the  institution  which  wants  to  implement  PMDUMP. 

PMDUMP  itself  can  work  almost  completely  independently  of  a  special 
operating  system  and  is  linked  to  the  system  using  a  set  of  parameters  in 
very  much  the  same  way  as  is  familiar  from  the  ALC0R -ILLINOIS -709O  ALG0L-6O 
Translator. 

PMDUMP  has  its  own  conversion  routines  built  in^  the  same  which 
are  used  in  7O9^-P0RTH0S  at  the  Department  of  Computer  Science  of  the 
University  of  Illinois, 

If  a  job  consists  of  several  core  loads  it  is  necessary  to  identify 
corresponding  object  codes  and  dump  informations.   For  this  purpose  an 
identification  must  be  put  into  columns  73~SO  of  "the  first  card  of  the  main 
Algol  program  in  each  core  load. 


III.   The  Loading  Map 


PMDUMP  is  designed  so  that  it  can  operate  with  or  without  having  a 
loading  map  available  (see  parameter  BLDMAP).   It  is  desirable^  however _,  that 
a  loading  map  be  provided  since  it  will  make  the  post  mortem  dump  more  powerful 
and  faster. 

If  a  loading  map  is  available  file  2  on  UTAPl  (see  also  section  VI ) 
contains  one  record  for  each  core  load  in  the  job.   This  record  has  the 
following  structure: 

Word  1;   ID  of  this  core  load_,  or  all  0  if  only  1  core  load  is  in  the  job. 

At  dump  time  word  1  is  matched  with  location  BC0RID  (see  parameters 
for  PMDUMP)  to  identify  the  loading  map  for  this  core  load. 

Word  2:   Not  used  by  PMDUMP.   In  the  Illinois  system  the  decrement  contains 
the  program  break  (highest  location  used  by  the  object  code  of  the 
main  program  including  all  subroutines+l)  of  this  core  load.   It  is 
used  by  )PREPM  to  allow  a  check  for  memory  overflow  in  multiple 
core  loads. 

Odd  words  >  3-   Contain  in  bits  S...1J+  the  first  location  of  the  routine 
whose  name  is  in  the  following  even  word. 

Even  words  >  h:      BCD  name  of  entry  of  the  routine.  v 
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IV.   Tape  Requirements 


At  most^  3  tapes  are  required  ty  PMDUMP^  one  at  compilation  time  and 
one  or  two  more  at  dump  time.   They  are  as  follows: 

UTAPl:   Used  at  compile  time  to  save  information  for  PMDUMP.   It  must  be 
rewound  before  the  first  Algol  compilation  in  a  job  is  started. 
UTAPl  must  not  be  touched  by  the  system  between  compilations  (e.g., 
a  main  program  with  several  precompiled  procedures)  in  the  same  job. 
The  system  must  write  an  End  of  File  on  UTAPl  after  all  compilations 
are  finished. 

File  2  on  UTAPl  contains  the  loading  map  if  it  is  available 
(see  section  III).   The  first  or  the  first  and  the  second  file 
(depending  on  whether  a  loading  map  is  not  or  is  available)  must 
be  saved  for  PMDUMP.   No  other  parts  of  UTAPl  except  these  first 
2  files  are  used  by  either  the  compiler ;,  )PREPM  or  PMDUMP. 


DUMP 
Information 


EOF 


Loading 
maps 


EOF 


/V\AAAAAAAA 


-> 


-> 


-> 


-> 


written  by  the  compiler  if  a  post  mortem 
dump  is  requested 


written  by  the  system  or  the  loader  after 
all  compilations  in  one  job  are  finished 


loading  maps  this  job^ 
provided  by  the  system 
or  the  loader 

written  by  the  system  or 
the  loader 


Optional 


see 


parameters 
BLDMAP 
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UTAPM2:    contains  one  file  to  save  the  object  code  part  of  the  dead  core 
after  a  breakdown.   This  file  is  written  by  routine  )PREPM. 

UTAPM3 :    contains  one  file  to  save  the  working  storage  area  of  the  dead 
core  after  breakdown.   This  file  is  written  by  routine  )PREPM. 


No  other  parts  of  UTAPM2  or  UTAPM3  are  used.   Furthermore^  UTAPM2 
and  UTAPM3  can  be  the  same  tape  in  which  case  some  speed  is  lost^  however. 
After  PMDUMP  the  tapes  UTAPM2  and  UTAPM3  are  again  positioned  in  front  of  the 
files  used. 


V.   PMDUMP  Parameters 


As  far  as  the  following  parameters  are  also  compiler  parameters, 
they  must  be  the  same  as  in  the  compiler. 


BPSTRT  EQU 
WADLEV  EQU 

BRETTE  EQU 

UTAPl  EQU 

UTAPM2  EQU 
UTAPM3  EQU 
BC0RID  EQU 

BNAMES  BCI  1; 
BCI  1, 


Lowest  location  used  "by  the  object  program  at  execution  time. 

Highest  location  used  by  the  object  program  (also  compiler 

parameter) , 

Locations  BRETTE,  BRETTE+1,  .  .  .  . ,  BRETTE+9  are  used  to  pass 

information  from  )PREPM  to  PMDUMP.   They  must  not  be  destroyed 

while  PMDUMP  is  brought  into  core. 

Logical  tape  used  by  pass  3  "to  save  dump  Information  (also 

compiler  parameter). 

Scratch  tape  at  dump  time. 

Scratch  tape  at  dump  time. 

Location  BC0RID  contains  the  identification  for  the  present 

core  load  (only  used  in  )PREPM). 

Names  of  all  entries  to  execution  time  subroutines  as 

appearing  in  the  loading  map. 


BCI  1, 
BNNAMS  EQU     Number  of  above  entries. 

ESCAPE  EQU  0   Never  give  an  octal  core  dump  even  if  a  total  analysis  of 
the  Algol  program  is  not  possible. 
4  0  Give  octal  dump  of  parts  of  the  dead  core  if  necessary. 

The  locations  ESCAPE,  ESCAPE+1,  ...,  ESCAPE  +  BL0NG  must 
lie  outside  of  the  region  BPSTRT,  BPSTRT +1,  ...,  WADLEV. 
Length  of  dead  core  records  on  UTAPM2  and  UTAPM3. 
Loading  map  is  available. 
Loading  map  is  not  available. 


BLDCR  EQU 
BLDMAP  PZE  1 
0 


BMIN  BCI  1,   Name  of  main  program  as  it  appears  in  the  loading  map. 


BL0NG  is  defined  in  PMDUMP. 
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The  following  sy stern  subroutines  are  needed  by  PMDUMP.   Below  are 
the  linkages  and  functions  of  each  subroutine.   If  your  subroutines  have 
different  linkages  write  subroutines  to  link  the  calls  listed  below  with 
your  subroutines.   These  linking  routines  must  be  added  to  the  PMDUMP 
parameters.   Symbolic  names  beginning  with  J  should  be  used  if  necessary. 
The  names  used  for  tapes  represent  logical  tape  numbers. 


TSX   SYSSTR,i+ 
PTH   A 


TSX 

SYSFPT,1+ 

XYZ 

L0C 

X=0 

EFTM 

X=l 

LFTM 

Y=0 

Y=l 

Z=0 

Z=l 

TRA   SYSTEM 
TSX   SYSSKR;^ 
TIX   A^^B 


Set  up  location  2  for  STR  instruction  to  pass 

control  to  A. 

See  compiler  parameters. 

See  compiler  parameters. 

The  prefix  bits  X;  Y  and 

Z  of  the  parameter  word  are  interpreted  as  follows : 

(Enter  floating  trap  mode) 

(Leave  floating  trap  mode) 

Use  system  floating  trap  processor  when  a  floating 

point  trap  occurs. 

Transfer  to  L0C  when  a  floating  point  trap  occurs. 

Do  not  change  AC  when  a  floating  point  trap  occurs. 

Let  logical  AC  =  contents  of  location  0  when  a 

floating  point  trap  occurs. 

See  compiler  parameters. 

See  compiler  parameters. 

See  compiler  parameters. 

See  compiler  parameters. 

See  compiler  parameters. 

Return  control  to  the  operating  system. 

Skip  A  records  on 

tape  B, 

See  compiler  parameters. 
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VI.   Compiler  Changes 


The  following  changes  must  be  made  in  the  ALC0R-ILLINSZ(lS-7O9O 
ALG0L-6O  Translator  to  make  it  compatible  with  PMDUMP: 


l)   Compiler  Parameters;   Parameter  UTAPl  must  now  be  defined  as  a  logical  tape 
number  and  the  following  parameters  must  be  added. 


PMDMPL 
PMDMPB 


EQU 
EQU 


If  at  compile  time^  bit  PMDMPB  of  location  PMDMPL 
is  ly    generate  dump  information  and  give  dump  in 
case  of  a  hangup  at  execution  time.   If  bit  PMDMPB 
is  0_,  do  nothing.   If  dump  is  always  or  never 
requested^  make  PMDMPL  EQU  A)VAR  and  PMDMPB  EQU  35 
or  30  resp. 


PPMDMP 


BCI    1, 


BCD  name  of  execution  time  routine  )PREPM. 


2)   Pass  1: 


a)  Replace  instruction  MM0UN6+1  by: 

TXH    MM0UN9^^,O 

b)  Insert  at  MM0UT6-1/2: 

MM0UN9 


CAL 

PMDMPL 

ARS 

35 -PMDMPB 

LBT 

TRA 

mm^ut6 

CAL 

PPMDMP 

TSX 

GTURN.i^ 

LXA 

WTVC1^2 

TXI 

*+l,2,l 

SXA 

WTVC1;2 

SLW* 

WTVCl 

SXD 

*+2,2 

LAC 

WTVC01,2 

TXI 

*+l,2^** 

SXD 

MIDEN0-l6,2 

GET  PM)UMP  W0RD 
GET  PMDUMP  BIT 
IS  DUMP  REQUESTED 
N0 

YES, PUT  NAME  0F 
R0UTINE  )PREPM 
INT0  TRANSFER 
VECTOR 


3)   Pass  2:   Insert  at  WEST0P-2  l/2: 

CLA    LABLN 
STA    MIDEN0-16 

^4-)   Pass  3:  An  entirely  new  Pass  3  must  be  used.   It  can  be  obtained  from 

the  Department  of  Computer  Science,  University  of  Illinois. 
5)  Pass  ^4-;   No  changes. 
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VII.   Execution  Time  Subroutine  )PREP]yr 


)PREPM  is  an  execution  time  subroutine  called  at  the  beginning 
of  every  Algol  prograin  for  which  a  post  mortem  dump  has  been  requested^  and 
again  at  the  time  of  breakdown.   For  explanatory  purposes  )PREPM  will  be 
divided  into  2  subprograms  IKDUMP  and  ADUMP. 

Since  )PREPM  is  systems  dependent  it  must  be  coded  by  each 
installation  using  PMDUMP.   The  functions  of  IKDUMP  and  ADUMP  are  described 
below.   It  may  not  be  possible  to  implement  all  error  returns. 

)PREPM  is  the  only  entry  point.   It  is  the  location  of  the  first 

executable  instruction  of  IKDUMP.   The  following  parameters  are  needed  and 

must  be  the  same  as  in  PMDUMP: 

WADLEV 

BRETTE 

UTAPl 

UTAPM2 

UTAPM3 

BLDCR 

BPSTRT 

BC0RID 

For  further  information  about  these  parameters^  see  section  V. 


l)  The  nomenclature  in  this  description  agrees  with  the  routine  )PREPM  as 
used  in  P0RTH0S  at  the  Department  of  Computer  Science  of  the  University 
of  Illinois. 
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VII.   1.   INDUMP 


INDUMP  is  called  at  the  start  of  every  Algol  program  for  which 
a  dump  has  been  requested.   It  does  the  following: 

1)  Saves  XRh.      Saves  the  indicators  if  they  are  used  by  INDUMP. 

2)  Gets  the  program  break  for  the  current  core  load  and  stores 
it  in  the  address  part  of  PGMBRK  (see  section  VII.  3* 
Communications  Area). 

3)  Stores  the  instruction  TXL  C0RC0N;,^^-1  in  the  region  between 
the  program  break  and  WADLEV.   (C0RC0N  is  the  error  return  point 
in  ADUMP  used  if  control  jujnps  out  of  the  object  program.  ) 

k)     Sets  up  a  time  trap  error  return  to  ADUMP.   (return  point:  ATMDMP) 

5)  Sets  up  a  memory  protect  violation  error  return  to  ADUMP. 
(return  point:  APRDMP) 

6)  Sets  up  a  return  to  ADUMP  from  a  normal  system  error  exit, 
(return  point:  ASYSER) 

7)  Sets  up  an  error  return  to  ADUMP  from  a  floating  point  trap, 
(return  point:  AFPDMP) 

8)  Sets  up  l/jZS  error  return  to  ADUMP.   (return  point:  AI0DMP) 

9)  Sets  up  the  error  return  to  ADUMP  from  the  execution  time 

subroutines  )ARDEC^  A)PTRA,  and  )AREAD.   This  is  done  by 

the  following  coding: 

)XERR 

XERRTN 

)XERR 

where  XERRTN  contains  the  instruction  TRA   AEXER 

where  AEXER  is  the  return  point  in  ADUMP  used  in  case  of  an  error 

in  one  of  the  above  routines  (see  section  VII.  h.      ")XERR").^, . 

10)  Sets  up  an  error  return  from  the  system  routines  used  by  the  standard 
functions  SIN,  COS,  SQRT,  LN,  EXP,  ARCTAN.   (return  point:  .EXIT) 

11)  Restores  XR^.   Restores  the  indicators  if  necessary.   Executes 
a  TRA  1,4  to  return  control  to  the  main  program. 


EXTERN 

CAL 

SLW* 


i 
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VII. 

2. 

ADUMP 

In 

the  case 

of  breakdown 

the 

initializations 

in 

IHDUMP  r 

eturn 

contr 

ol 

to 

an 

error  entry  in 

ADUMP.   ADUMP 

does  the  following: 

1) 

Disable 

s  the  system  error  returns  of  INDUMP 

wherever 

poss 

ible. 

2) 

Complet 

es  filling  in 

the 

communications 

reg: 

Lon  (see 

section 

■ 

VII.  3. 

"Communicat: 

Lons 

Area/'  below). 

3)  Writes  out  the  object  code  and  working  storage  on  tape  for  use 
by  PMDUMP.   Depending  on  the  option  chosen  (see  section  IV. 
"Tape  Requirements")^  this  is  done  as  follows: 

Case  1  UTAPM2  and  UTAPM3  separate  tapes. 

a)  Saves  the  object  code  (from  BPSTRT  to  the  program 
break)  on  UTAPM2. 

b)  Saves  the  working  storage  on  UTAFM3.   The  lowest 
location  used  for  storage  is  <ALPHA>^ 

(see  "communication  region"^  below).   The 
highest  location  used  is  WADLEV. 
Note:   Information  on  tapes  is  written  out  in  records  of 
length  BLDCR  except  possibly  the  last  record  on 
each  tape  which  may  be  shorter.   This  information 
must  either  be  at  the  beginning  of  the  tape  or 
preceded  by  an  E0F. 

c)  Writes  a  terminal  EjZ5F  on  UTAPM2  and  UTAPM3. 


Case  2  UTAPM2  and  UTAPM3  combined  into  1  tape,  UTAPM2. 

a)  Writes  the  object  code  on  UTAPM2  in  records  of  length 
BLDCR  (except  possibly  the  last  record  which  may 

be  shorter).   This  information  must  either  be  at  the 
beginning  of  the  tape  or  preceded  by  an  E0F. 

b)  Writes  the  working  storage  on  UTAPM2  immediately  after 
the  object  code  in  records  of  length  BLDCR  except 
possibly  the  last  record  which  may  be  shorter.   (See 
Case  1,  b. ) 

1)  For  notation  see  "User's  Manual  for  the  ALC0R-ILLINjZ5lS-7O9O  ALG0L-6O 
Translator,  2nd  Edition,  Section  9»2« 
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c)  Writes  a  terminal  E0F  on  UTAFM2. 

h)     Positions  UTAPM2,  UTAPM3,  (UTAPM2)  at  the  start  of  the  files 
(file)  just  written  out. 

5)  Moves  the  communications  area  to  BRETTE^  BRETTE+l^ . . . ^ 
BRETTE+9. 

6)  Brings  PMDUMP  into  core^  turns  control  over  to  it. 
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VII.   3»   Communications  Area 


The  communications  area  contains  information  needed  by  PMDUMP.   It 
has  the  following  form: 


XR1XR2 

PZE 

XRl, ,XR2 

XR4ILC 

.PZE  . 
^MZE  ^ 

XRi+,,ILC 

XSUBR 

PZE 

XRISUB, , ILCSUB 

C0RID 

PZE 

C0RE  L0AD  ID. 

K0RK0N 

TXL 

C0RC0N,^,-1 

CDRCN0 

PZE 

0BJECT  REC.  N0.,,O 

DFSRCN 

PZE 

STORAGE  REC.  NjZS.,,0 

PGMBRK 

PZE 

PROGRAM  BREAK,, XR2SUB 

ALPHA 

PZE 

L0WEST  WORKING  STORAGE,, 0 

SWITCH 

PZE 

NUMBER,, 0 

1)  XR1XR2    contains  the  contents  of  index  registers  1  and  2  at  the  time 

of  breakdown.   (See  "notes  on  machine  conditions",  end  of 
this  section). 

2)  XR^ILC    contains  the  contents  of  index  register  h   and  the  value  of 

the  instruction  location  counter  (ILC)  at  the  time  of  breakdown. 
If  it  is  known  that  the  ILC  is  meaningless  (e.g.,  return  by- 
execution  of  TXL  C0RC0N,i+,-l)  the  prefix  is  MZE,  otherwise 
PZE. 

3)  XSUBR     contains  <)X1ILC>  (See  section  VII.  h.     )XERR. ) 

k)      C^RID     contains  the  core  load  identification  if  a  loading  map  is 
available,  (see  section  III). 

5)  K0RK0N    TXL  C0RC0N,4,-1   (see  section  VII.  1.  lEDUMP,  3-) 

6)  CDRCNjZJ    contains  the  number  of  records  of  object  code  written  out  on 

UTAPM2  in  the  address  (see  section  VII.  2.  ADUMP,  3.) 

7)  DFSRCN    contains  the  number  of  records  of  working  storage  written  out  on 

UTAPM3  (UTAPM2)  in  the  address.   (See  section  VII.  2.  ADUMP,3.) 
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8)  PGMBRK    contains  the  program  break  (see  section  VII.  1.  IIIDUMP,  2) 

in  the  address^  <)X2Xi+>^  (see  section  VII.  h.    )XER]0  in 
the  decrement. 

9)  ALPHA     a)   If  breakdown  occurs  in  the  Algol  generated  code  or  in 

an  Algol  execution  time  subroutine,  <ALPHA>/\^  contains  <nroiCATORS> 
at  the  time  of  breakdown, 
b)   If  breakdown  occurs  elsewhere  and 

1)  the  indicators  have  not  been  destroyed  since  control 
was  passed  from  the  Algol  code  ALPHA  is  as  in  part  a). 

2)  the  indicators  have  been  destroyed  then  <ALPHA>„  is 
<indicators>A  prior  to  the  destruction  of  the 
indicators  by  the  present  routine. 

10)   SWITCH    the  numerical  value  of  NUMBER  determines  the  conclusion  of  the 
error  message  "PMDUMP  CALLED  BECAUSE  0F  -  -  -"  which  will  be 
printed  out  by  PMDUMP.   The  decimal  values  of  NUMBER  and  the 
associated  errors  are  given  below. 


NUMBER 


ERROR 


1 
2 
k 
8 

16 
32 

0 


job  overtime 

floating  point  error 

memory  protect  violation 

control  jumped  outside  of  object 

program.   TKL   CJ25rC0N,4, -1  executed. 

1/0  error 

job  terminated  via  the  normal 

system  error  exit 

all  other  errors 


If  NUMBER  =  0,  PMDUMP  will  give  no  indication  of  the  type  of  error  occurring 
Any  desired  error  messages  must  be  printed  out  by  the  routine  in  which  the 
errors  occur,  ( )AREAD,  )ARDEC,  A)PTRA  do  this)  or  by  ADUMP. 
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Notes  on  Machine  Conditions 


To  make  a  successful  analysis  PMDUMP  must  find  meaningful  machine 
conditions  in  the  communications  region  (i.e.  values  of  index  registers  1^2^^ 
and  of  the  instruction  location  counter  current  at  the  latest  time  program 
control  was  held  by  the  Algol  code).   If  machine  conditions  at  the  time 
control  is  passed  to  an  error  return  point  in  ADUMP  are  meaningless 
(e.g.  machine  conditions  of  a  trap  processor),  meaningful  conditions  must 
be  recoveredby  ADUMP  and  these  values  put  in  the  communications  region. 

If  meaningful  values  cannot  be  recovered  for  all  machine  conditions 
a  successful  analysis  may  or  may  not  be  made,  depending  on  the  program  being 
analyzed.   It  is  always  necessary  to  have  either  a  meaningful  index  register  1 
or  instruction  location  counter.   If  both  are  meaningful  it  is  quite  likely 
that  the  analysis  will  be  successful.   Index  registers  2  and  k   are  generally 
the  least  crucial. 

If  return  comes  from  an  execution  time  subroutine  (return  point  AEXER) 
or  from  a  system  l/0  routine  (return  point  AI0DMP)  machine  conditions  will  be 
meaningless.   In  these  cases  meaningful  values  will  be  found  in  the  execution 
time  subroutine  )XERR  (see  section  VII.  h.    )XERR)  and  XRIJCR2,  XRUILC  should  be 
filled  as  follows : 

XR1XR2    PZE    <)X1ILC>/^  ,,    <)X2Xk>^ 

XRklLC        FIE  <)XlILC>j~)  ,,   <)XlILC>j^  complemented 
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VII.  h.       )XERR 


<»v  ! 


)XERR  is  an  execution  time  subroutine  serving  as  a  common  error 
exit  for  A)PTRA^  )ARDEC^  and  )AREAD;  and  as  a  storage  area  for  information 
needed  by  PMDUMP.   It  consists  entirely  of  the  following: 

)XERR    TRA     SYSTEM 
)X1ILC    PZE 
)X2Xi+    PZE 

where  )XERR,  )X1ILC,  )X2Xi+  are  entry  points. 

Immediately  upon  entry  the  execution  time  subroutines  A)PTRA^ 
)APliEC;,  )AREAD;  )AF0RM;,  and  )APRIN  store  index  registers  1  and  2  and  the 
complement  of  the  calling  point  in  )X1ILC^  )X2X4.   This  allows  for  the 
following: 

1)  If  breakdown  occurs  in  an  execution  time  subroutine  or  during 
1/0  ADUMP  can  recover  meaningful  values  from  )X1ILC^  )X2X^. 
(See  section  VII.  3-  Notes  on  machine  conditions). 

2)  If  breakdown  occurs  in  a  thunk  called  by  an  execution  time 
subroutine  and  a  loading  map  is  available^  PMDUMP^  after 
determining  that  the  calling  point  of  the  thunk  is  in  an 
execution  time  subroutine  will  use  <)X1ILC>;,  <X2X^>^  to 
continue  its  analysis  beyond  the  calling  point  of  the 
thunk. 


1)  See  "User's  Manual  for  the  ALC0R- ILLINOIS -7 O9O  ALG0L-6O  Translator" 
2nd  Edition,  section  9. 10. 6.1. 
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